System and method for transaction access control

ABSTRACT

A computer implemented system controls transaction access of requester applications running on end-user computers having network protocol addresses, to internal applications and their associated transactions running in internal transaction areas of host computer systems. Related to each network protocol address, a requester database contains information related to each network protocol address including end-user identification, possible usename and password and instructions, possible priority levels of select transactions, and authorized transactions. A listener listens for a connect request from one of the end-user computers. A validator, using the requester database, determines whether the end-user computer has a valid network protocol address. An external communication module receives subsequent transaction requests from validated end-user computers and a validator in conjunction with a requester database determines among other things whether the transactions requested are authorized for particular end-user computers. Usernames and passwords are sent to an external security manager for authorized transactions.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The invention relates generally to computer applications, systemsand methods, and more particularly to computer systems and methods forcontrolling access to transactions associated with an internaltransaction area of a host computer.

[0003] 2. Description of the Related Art

[0004] Conventional host computer systems provide services for typicallylarge numbers of end-users using end-user computers such as terminals,personal computers, workstations, and computer servers. The services arefurnished through internal applications running in internal transactionareas of the host computer systems, which allow for series oftransactions to occur between the host computer systems and the end-usercomputers. Each transaction is typically a bounded unit of work orfinite task associated with an internal transaction area. Any particularinternal transaction area has numerous associated transactions, so theexamples given herein are merely representative and exemplary in natureand not to be construed to be all-inclusive. For instance, a transactioncould return data, or could put data, or could add data.

[0005] Access to the internal applications and their associatedtransactions is typically authorized based upon the sensitivity of theinternal applications and their associated transactions compared withthe degree of physical security precautions implemented in theparticular locale in which the end-user computers are located. Forinstance, regarding internal application sensitivity, if the internalapplications and their related transactions are associated with suchdata as financial data, inventory data, trade secret data, or managementplanning data, the applications and transactions would most likely beviewed as having a relatively high level of sensitivity. On the otherhand, if the internal applications and their associated transactions arerelated to information readily obtained by the general public such asretail prices of particular items, general news, or other types ofgeneral interest data, the internal applications and their associatedtransactions would most likely be viewed as having a lesser level ofsensitivity.

[0006] Regarding physical security, a relatively high degree of physicalsecurity, for instance, could involve end-user computers being locatedin buildings having physically controlled access, such as through mannedcheckpoints, barriers operated by badge reading devices, and lockeddoors. A relatively high degree of physical security could also involveend-user computers having communication nodes that were directly tiedinto the host computer system and were difficult to remove from theirlocale. A relatively low degree of physical security, for instance,could involve the end-user computers being located in areas accessibleto the general public or using communication nodes that were shared withthe general public.

[0007] If an internal application and its associated transactions aredeemed to have a relatively high degree of sensitivity, oftentimes, ifat least one or a few number of end-user computers have a relatively lowdegree of associated physical security, then correct input of usernames(user-identification) and passwords is required of all of the associatedend-users using any end-user computer, regardless of the physicalsecurity of the end-user computer involved, in order to be given properauthorization to access the internal application and associatedtransactions. Other times, a particular internal application and itsassociated transactions could be deemed as having a relatively highenough degree of sensitivity that input of usernames and passwords wouldbe required not only to access the particular internal application andits associated transactions, but also to access other internalapplications running on the host computer system regardless of thephysical security of any associated end-user computer.

[0008] It is unfortunate in these conventional approaches that ifusernames and passwords are required by a host computer system ofend-users of particular end-user computers to access an internalapplication of the host computer system, the requirement is generallyimposed upon all end-users of any end-user computers, regardless of thephysical security of the end-user computers. The inflexibility of theseconventional approaches, at times, introduces unnecessary inconvenienceto some, if not many of the end-users of a particular internalapplication. The end-user computer with the relatively lowest level ofphysical security is a decisive reason regarding the requirement forentry of usernames and passwords for an entire group of end-usercomputers accessing the particular internal application and itsassociated transactions.

[0009] To compound the inconvenience, oftentimes a particular internalapplication and its associated transactions with the relatively highestlevel of sensitivity is also another decisive reason for the requirementfor entry of usernames and passwords. Consequently, even though some ormost of a group of internal applications and their associatedtransactions running on a host computer system have a relatively lowlevel of sensitivity that requires no entry of usernames and passwordsregardless of the physical security of the end-user computer, entry ofusernames and passwords is still required because of a relatively highlysensitive internal application and its associated transactions runningon the host computer system.

[0010] Herein are described computer based systems and methods directedtoward these and other issues. Other features and advantages will becomeapparent from the following detailed description, taken in conjunctionwith the accompanying drawings.

SUMMARY OF THE INVENTION

[0011] A transaction access control system is for use with an internaltransaction area and an internal application running in the internaltransaction area on a host computer connected to a network, for use withan external security manager configured to receive and authenticate afirst plurality of pairs of usernames and passwords to permit or denyaccess to the internal transaction area, and for use with a firstplurality of end-user computers communicatively linked to the hostcomputer via the network, the end-user computers each having at leastone of a first plurality of network protocol addresses and a requesterapplication. Aspects include a requester database configured to containfor each of the first plurality of network protocol addresses of thefirst plurality of end-user computers, an associated one of the firstplurality of pairs of usernames and passwords. A controller isconfigured to receive the first plurality of network protocol addressessent from the first plurality of the end-user computers via the networkand received by the host computer.

[0012] Further aspects include a validator configured to retrieve fromthe requester database each of the first plurality of username andpassword pairs associated with each of the first plurality of networkprotocol addresses based upon at least each of the first plurality ofnetwork protocol addresses. The controller is further configured totransmit each of the retrieved username and password pairs to beauthenticated by the external security manager to permit access to theinternal transaction area to each of the requester applications of theend-user computers having the first plurality of network protocoladdresses which are associated with the retrieved username and passwordpairs.

[0013] Other features and advantages of the invention will becomeapparent from the following detailed description, taken in conjunctionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 is a schematic diagram of a computing system suitable foremploying implementations described herein.

[0015]FIG. 2 is a schematic diagram illustrating an implementation of atransaction access control system to control access to transactions ofinternal applications running in an internal transaction area on a hostcomputer by a requestor application running on an end-user computer.

[0016]FIG. 3 is a communication diagram showing interactions between therequestor application, a listener, an external communication module, anaccess state controller, a validator, and an internal applicationassociated with the transaction access control system, as illustrated inFIG. 2.

[0017]FIG. 4 is a flowchart illustrating a method implemented by thelistener associated with the transaction access control system, asillustrated in FIG. 2, to receive initial connection from end-usercomputers.

[0018]FIGS. 5A, 5B, and 5C combine to describe a flowchart illustratinga method implemented by the external communication module associatedwith the transaction access control system, as illustrated in FIG. 2.

[0019]FIG. 6 is a flowchart illustrating a method implemented by thevalidator associated with the transaction access control system, asillustrated in FIG. 2, for validator preparation.

[0020]FIG. 7 is a flowchart illustrating a method implemented by thevalidation associated with the transaction access control system, asillustrated in FIG. 2, for end-user validation.

[0021] FIGS. 8 is a flowchart illustrating a general method implementedby the validator associated with the transaction access control system,as illustrated in FIG. 2, for transaction validation.

[0022]FIG. 9 is a flowchart illustrating a more particular methodimplemented by the validator associated with the transaction accesscontrol system, as illustrated in FIG. 2, for transaction validation.

DETAILED DESCRIPTION OF THE INVENTION

[0023] Described herein are systems and methods for transaction accesscontrol of requester applications running on end-user terminal-emulatorcomputers, client computers, and/or server computers to control accessto internal applications and their associated transactions running ininternal transaction areas of host computer systems. The transactionaccess control systems are configured to operate cooperatively withexternal security managers that are conventionally provided to operatewith the internal transaction areas and that are configured to receiveand authenticate a plurality of pairs of usernames and passwords topermit or deny access to the internal transaction areas based uponusername-password authentication. The transaction access control systemsand methods use network protocol addresses, such as IP and IPX, of theend-user requester computers running the requester applications toidentify particular end-user computers requesting access to particularinternal applications and their associated transactions. A requesterdatabase contains fields including those identifying network protocoladdresses (such as either individual addresses or ranges of addresses)of the end-user computers, and at least some of the following associatedwith each network protocol address: identification of the associatedend-user, the username or other identifier of the end-user and passwordto be used if any, instructions regarding use of the username andpassword (such as whether the end-user should be challenged to submittheir username and password and if a challenge is required, whether thesubmitted username and password should be verified with respect to therequester database before being sent to the external security manager),transaction execution priorities (for instance, containing designatorspossibly indicating priorities based upon transaction type, end-userinvolved, or a combination), and authorized transactions available.

[0024] The requester database allows an administrator to associateend-users with particular network protocol addresses. The administratorcan customize how the transaction access control system will respond totransaction access requests by various end-users using end-usercomputers based upon the network protocol address of the particularend-user computer that is being used. For instance, the administratorcan configure the transaction access control system so that for givennetwork protocol addresses requesting certain transactions involvingparticular internal applications, usernames and passwords stored in therequester database are supplied to the external security manager of thehost computer system to allow the end-user computers associated with thegiven network protocol addresses, access to the certain transactionsinvolving particular internal applications.

[0025] Other end-user computers associated with other network protocoladdresses can be denied access or challenges can be issued by thetransaction access control system. For instance, a challenge can beissued requesting the username and password of the end-user using theparticular end-user computer. The username and password furnished by theend-user can be optionally compared by the transaction access controlsystem with the associated username and password stored in the requesterdatabase. The furnished username and password is sent to the externalsecurity manager of the host computer system if the optional comparisonis not made or the optional comparison is made with a successful matchoccurring. The administrator has flexibility in assigning variouspriorities to different network protocol addresses so that transactionaccess requests by end-user computers are given different treatmentregarding execution scheduling depending on the priorities assigned. Theadministrator can also identify which transactions are authorized for aparticular network protocol address so that unauthorized transactionrequests are denied before reaching the internal area access of the hostcomputer system and its associated external security manager.

[0026] In these and other ways, the transaction access control systemacts as a front end to the internal transaction area of the hostcomputer system and its external security manager to offload initialsecurity filtering of transaction requests such that in general onlyauthorized transaction requests by validated end-user computers reachthe internal transaction area of the host computer system and itsassociated external security manager. Also, potential exists for greaterconvenience to the end-users relative to conventional approaches sincerequirements for username and password entry can be identified toparticular network protocol addresses and their associated end-usercomputers.

[0027] Further consequences of the transaction access control system caninclude generally eliminating the necessity for end-users to knowmainframe usernames and passwords. Initial screening and front endsecurity can be increased without over-burdening existing host securitysystems. Remote configuration of requester databases associated with thetransaction control system need not require systems programmingknowledge. Network protocol address ranges (such as IP or IPX addressranges) can be tailored to correspond to enterprise organizations,geographies, or job categories. Competing transaction requests can beprioritized through use of the requester database and network protocoladdresses based upon attributes such as related to organization,geography, transaction type, or transaction runtime characteristics(such as being batch oriented, burst oriented, real-time interactive,associated with application systems type, or having externally imposedpriorities). Redirection of transaction requests based upon theirnetwork protocol addresses to other host computer systems can betransparent to the end-user. Categories of transaction requests can bechanneled to specific regions of the internal transaction area of thehost computer system, to increase efficiencies, based upon the networkprotocol addresses of the transaction requests. Usernames and passwordscan be provided by the transaction access control system based upon thenetwork protocol addresses to facilitate access to internal transactionareas where no traditional logon was possible due to limitations ofparticular host internal area access systems (such as bridges) involved.Potential for challenged responses from the host internal area accesssystem is possible to allow for real-time collection of usernames andpasswords from the end-users.

[0028] In the following description, numerous specific details areprovided to understand implementations. One skilled in the relevant art,however, will recognize that the invention can be practiced without oneor more of these specific details, or with other equivalent elements andcomponents, etc. In other instances, well-known components and elementsare not shown, or not described in detail, to avoid obscuring aspects ofthe invention or for brevity. In other instances, the invention maystill be practiced if steps of the various methods described could becombined, added to, removed, or rearranged.

[0029]FIG. 1 and the following discussion provide a brief, generaldescription of a suitable computing environment. Although not required,implementations of the present invention will be described in thegeneral context of computer-executable instructions, such as programapplication modules, objects, or macros being executed by a personalcomputer. Those skilled in the relevant art will appreciate that theinvention can be practiced with other computer system configurations,including hand-held devices, multiprocessor systems,microprocessor-based or programmable consumer electronics, network PCs,mini computers, mainframe computers, and the like. Implementations canbe practiced in distributed computing environments where tasks ormodules are performed by remote processing devices, which are linkedthrough a communications network including wired and wirelessenvironments. In a distributed computing environment, program modulesmay be located in both local and remote memory storage devices.

[0030] Referring to FIG. 1, a conventional personal computer, referredto herein as a client computer 10, includes a processing unit 12, asystem memory 14 and a system bus 16 that couples various systemcomponents including the system memory to the processing unit. Theclient computer 10 will at times be referred to in the singular herein,but this is not intended to limit implementations to a single clientcomputer since in typical implementations, there will be more than oneclient computer or other device involved. The processing unit 12 may beany logic processing unit, such as one or more central processing units(CPUs), digital signal processors (DSPs), application-specificintegrated circuits (ASICs), etc. Unless described otherwise, theconstruction and operation of the various blocks shown in FIG. 1 are ofconventional design. As a result, such blocks need not be described infurther detail herein, as they will be understood by those skilled inthe relevant art.

[0031] The system bus 16 can employ any known bus structures orarchitectures, including a memory bus with memory controller, aperipheral bus, and a local bus. The system memory 14 includes read-onlymemory (“ROM”) 18 and random access memory (“RAM”) 20. A basicinput/output system (“BIOS”) 22, which can form part of the ROM 18,contains basic routines that help transfer information between elementswithin the client computer 10, such as during start-up.

[0032] The client computer 10 also includes a hard disk drive 24 forreading from and writing to a hard disk 25, and an optical disk drive 26and a magnetic disk drive 28 for reading from and writing to removableoptical disks 30 and magnetic disks 32, respectively. The optical disk30 can be a CD-ROM, while the magnetic disk 32 can be a magnetic floppydisk or diskette. The hard disk drive 24, optical disk drive 26 andmagnetic disk drive 28 communicate with the processing unit 12 via thebus 16. The hard disk drive 24, optical disk drive 26 and magnetic diskdrive 28 may include interfaces or controllers (not shown) coupledbetween such drives and the bus 16, as is known by those skilled in therelevant art. The drives 24, 26 and 28, and their associatedcomputer-readable media, provide nonvolatile storage of computerreadable instructions, data structures, program modules and other datafor the client computer 10. Although the depicted client computer 10employs hard disk 25, optical disk 30 and magnetic disk 32, thoseskilled in the relevant art will appreciate that other types ofcomputer-readable media that can store data accessible by a computer maybe employed, such as magnetic cassettes, flash memory cards, digitalvideo disks (“DVD”), Bernoulli cartridges, RAMs, ROMs, smart cards, etc.

[0033] Program modules can be stored in the system memory 14, such as anoperating system 34, one or more application programs 36, other programsor modules 38 and program data 40. The system memory 14 also includes abrowser 41 for permitting the client computer 10 to access and exchangedata with sources such as web sites of the Internet, corporateintranets, or other networks as described below, as well as other serverapplications on server computers such as those further discussed below.The browser 41 in the depicted implementation is markup language based,such as Hypertext Markup Language (HTML), Extensible Markup Language(XML) or Wireless Markup Language (WML), and operates with markuplanguages that use syntactically delimited characters added to the dataof a document to represent the structure of the document. Although thedepicted implementation shows the client computer 10 as a personalcomputer, in other implementations, the client computer is some othercomputer related device such as a personal data assistant (PDA) or acell phone or other mobile device.

[0034] While shown in FIG. 1 as being stored in the system memory 14,the operating system 34, application programs 36, other programs/modules38, program data 40 and browser 41 can be stored on the hard disk 25 ofthe hard disk drive 24, the optical disk 30 of the optical disk drive 26and/or the magnetic disk 32 of the magnetic disk drive 28. Included withthe application programs 36 and with the other programs/modules 38, orterminal emulation programs. A user can enter commands and informationinto the client computer 10 through input devices such as a keyboard 42and a pointing device such as a mouse 44. Other input devices caninclude a microphone, joystick, game pad, scanner, etc. (not shown).These and other input devices are connected to the processing unit 12through an interface 46 such as a serial port interface that couples tothe bus 16, although other interfaces such as a parallel port, a gameport or a wireless interface or a universal serial bus (“USB”) can beused. A monitor 48 or other display device is coupled to the bus 16 viaa video interface 50, such as a video adapter. The client computer 10can include other output devices, such as speakers, printers, etc.

[0035] The client computer 10 can operate in a networked environmentusing logical connections to one or more remote computers, such as aserver computer 60. The server computer 60 can be another personalcomputer, a server, another type of computer, or a collection of morethan one computer communicatively linked together and typically includesmany or all of the elements described above for the client computer 10.The server computer 60 is logically connected to one or more of theclient computers 10 under any known method of permitting computers tocommunicate, such as through a local area network (“LAN”) 64, or a widearea network (“WAN”) or the Internet 66 wherein the server computer 60is communicatively linked by a conventional network connectivity 67.Such networking environments are well known in wired and wirelessenterprise-wide computer networks, intranets, extranets, and theInternet. Other implementations include other types of communicationnetworks including telecommunications networks, cellular networks,paging networks, and other mobile networks.

[0036] When used in a LAN networking environment, the client computer 10is connected to the LAN 64 through an adapter or network interface 68(communicatively linked to the bus 16). When used in a WAN networkingenvironment, the client computer 10 often includes a modem 70 or otherdevice, such as the network interface 68, for establishingcommunications over the WAN/Internet 66. The modem 70 is shown in FIG. 1as communicatively linked between the interface 46 and the WAN/Internet66. In a networked environment, program modules, application programs,or data, or portions thereof, can be stored in the server computer 60.In the depicted implementation, the client computer 10 iscommunicatively linked to the server computer 60 through the LAN 64 orthe WAN/Internet 66 with TCP/IP middle layer network protocols; however,other similar network protocol layers are used in other implementations.Those skilled in the relevant art will readily recognize that thenetwork connections shown in FIG. 1 are only some examples ofestablishing communication links between computers, and other links maybe used, including wireless links.

[0037] In some implementations, the server computer 60 is furthercommunicatively linked to a legacy host data system 80 typically throughthe LAN 64 or the WAN/Internet 66 or other networking configuration suchas a direct asynchronous connection (not shown) wherein the legacy hostdata system 80 is communicatively linked by the network connectivity 67.With other implementations, the client computer 10 is furthercommunicatively linked (not shown) to the legacy host data system 80typically through the LAN 64 or the WAN/Internet 66 or other networkingconfigurations such as a direct asynchronous connection. Otherimplementations may support the server computer 60 and the legacy hostdata system 80 by one computer system by operating all serverapplications and legacy host data system on the one computer system. Thelegacy host data system 80 in an exemplary implementation is anInternational Business Machines (IBM) 390 mainframe computer configuredto support IBM 3270 type terminals. Other exemplary implementations useother vintage host computers such as IBM AS/400 series computers, UNISYSCorporation host computers, Digital Equipment Corporation VAX hostcomputers and Asynchronous host computers as the legacy host data system80. The legacy host data system 80 is configured to run hostapplications 82 such as in system memory and store host data 84 such asbusiness related data.

[0038] An exemplary implementation uses Sun Microsystems Javaprogramming language to take advantage of, among other things, thecross-platform capabilities found with the Java language. For instance,exemplary implementations include the server computer 60 running WindowsNT, Win2000, Solaris, Apple MacIntosh OS (e.g. 9.x or X) or Linuxoperating systems. In exemplary implementations, the server computer 60runs Apache Tomcat/Tomcat Jakarta web server, Microsoft InternetInformation Server (ISS) web server, or BEA Weblogic web server.

[0039] Apache is a freely available Web server that is distributed underan “open source” license and runs on most UNIX-based operating systems(such as Linux, Solaris, Digital UNIX, and AIX), on otherUNIX/POSIX-derived systems (such as Rhapsody, BeOs, and BS2000/OSD), onArnigaOS, and on Windows 2000/NT/95/98/ME. Windows-based systems withWeb servers from companies such as Microsoft and Netscape arealternatives, but Apache web server seems suited for enterprises andserver locations (such as universities) where UNIX-based systems areprevalent. Other implementations use other web servers and programminglanguages such as C, C++, and C#.

[0040] A transaction access control system 100 is illustrated in FIG. 2as running on the legacy host data system 80. Included on the legacyhost data system 80 of the transaction control system 100 is an internaltransaction area 102 with internal applications 104. Also included is acommunication protocol 106, a listener 108, and external communicationmodule (ECM) 110, an access state controller 112, a requester database114, an external security manager 116, and a validator 118. For someimplementations, when needed, a host internal area access 113 is alsoincluded to provide access to the internal transaction area 102. Thetransaction control system 100 is connected by a network such as the LAN64 or WAN/Internet 66 to an end-user computer 120 being one of theclient computers 10 as a personal computer/workstation or as a terminalemulation program platform, or being one of the server computers 60.

[0041] The end-user computer 120 runs a requester application 121 and isconnected to the LAN 64 or the WAN/Internet 66 to use the communicationprotocol 106 to communicate with the legacy host data system 80including the transaction control system 100. In some implementations,the requester application 121 typically includes an application programinterface (API) written in the perspective of a high-level language suchas High Level Language Application Programming Interface (HLLAPI),Server Enterprise Access Class Library (SEACL) (Attachmate Corp.,Bellevue, Washington), etc. to indicate, for instance, row and column ofa virtual computer terminal from or into which data is to be extractedor placed. In other implementations, one or more of the client computers10 and/or the server computers 60 can be running a terminal emulation tocommunicate with the legacy host data system 80 via the communicationprotocol 106. The transaction access control system 100 is connected bya network such as the LAN 64 or WAN/Internet 66 to a configurator 122being one of the client computers 10 as a personal computer/workstationor as a terminal emulation program platform, or being one of the servercomputers 60. The configurator 122 allows an administrator to configurethe requester database 114 remotely through graphical user interfaceswithout sophisticated systems level expertise required. In otherimplementations, the configurator 122 is located on the legacy host datasystem 80. In implementations, some components of the transaction accesscontrol system 100, such as the validator 118 and the requester database114, can be located on computers other than the legacy host data system100 receiving a particular transaction request from the end-usercomputer 120. Relocation of some components of the transaction accesscontrol system 100 may provide advantages such as related to performanceefficiencies or resource allocation issues.

[0042] In some implementations, the access state controller 112 controlsinvocation of the host internal area access 113 across multiple internalapplications 104 and maintains in-transaction and out-of-transactionstates necessary to satisfy the host internal area access, the internaltransaction area 102, and other areas of the legacy host data system 80of the transaction access control system 100. In these implementations,the access state controller 112 maintains the state of the host internalarea access 113, and interface components of the requester applications121 while only requiring the requester applications to maintaintransactions through conventional screen-scraping interfaces and othermechanisms familiar with developers of external applications.Furthermore, the access state controller 112 analyzes addresses ofreceived communication from the requester applications 121 with respectto state information of associated internal applications 104 running inthe designated internal transaction area 102. Based upon this analysis,the access state controller 112 either sends communication from therequester applications 121 in a format compliant with the internaltransaction area 102 to one of the internal applications 104 in theinternal transaction area via a host internal area access 113 or firstsend communication to a virtual host terminal (not shown) also runningon the same legacy host data system 80 of the internal transaction area.The virtual host terminal reflects what a computer terminal handlingcommunication compliant with the internal transaction area would displaywhen operating on a network and is described in a co-pendingapplication.

[0043] In implementations of the transaction access control system 100,the host internal area access 113 can be systems including host bridges,bridge exits, and program exits to allow communication with one or moreof the internal applications 104 running in the internal transactionarea 102 of the legacy host computer system 80. These implementations ofthe host internal area access 113 allow for one or more cycle points ofthe internal applications 104, which give control of the internalapplications to applications external to the internal transaction area102 including host and client applications and modules that run outsideof the internal transaction area. This control of the internalapplications 104 allows end-users of the external applications, such asthe requester applications 121, to access internal application data,which would otherwise typically be accessed through antiquated legacyapplication systems. In order to access the internal applications 104through the host internal area access 113, in some implementations, asdescribed, languages oriented toward the internal transaction area 102of the legacy host computer system 80 are used. In otherimplementations, the host internal area access 113 is configured suchthat the access state controller 112 is not required to the extentdescribed, but is still used in conjunction with the validator 118 inthe requester database 114 as described below.

[0044] Furthermore, host internal area access systems conventionallyused without benefit of the transaction access control system 100typically do not readily facilitate secured transactions such as whenusernames and passwords are used. Consequently, those conventionallyinvolved with applications external to the internal transaction area 102must develop workarounds conventionally used to address requirementsassociated with secured transactions such as providing usernames andpasswords. Unfortunately, these conventional workarounds tend only to bepartially satisfactory. For instance, conventionally used applicationsexternal to the internal transaction area 102 have limited ability tocommunicate with the host internal area access 113 regarding aspectsrelated to secure transactions, which results in the applicationsexternal to the internal transaction area having no feedback as towhether the usernames and passwords, which are sent, are correct. Incases when usernames and passwords are incorrectly provided by theexternal applications, the secured transactions with the host internalarea access systems fail without indication of the failure provided tothe external applications.

[0045] The host internal area access 113 generally does not provideprompts or sign-on screens when the internal transaction area 102 andthe internal applications 104 require usernames and passwords for accessby the external applications, such as when the internal transaction areainvolves International Business Systems (IBM) Customer InformationControl System (CICS) with a sign-on transaction based security system.It is possible for conventional approaches to use external applicationsthat themselves prompt and save usernames and passwords to insert intoevery transaction into the access state controller 102, however, theseapproaches only partially address the problems involved. If usernamesand passwords are managed by the applications external to the internaltransaction area to be provided with every transaction into the hostinternal area access 110, problems arise when a username or password isimproperly entered by an end-user.

[0046] Given the configuration of the typical host internal area access113 and how the applications external to the internal transaction areamay implement management of usernames and passwords, if an improperusername or password is entered by an end-user and forwarded to the hostinternal area access 113, the transaction would simply fail without astatus message regarding the username or password ever being sent backto the external application. End-users of applications external to theinternal transaction area would experience failure in communication withthe internal transaction area 102 and the internal applications 104without appreciating the source of their problems. They may naturally beled to believe that the source of the communication failures was somehowlocated in the internal transaction area 102 without realizing that thesource of the communications problems was due to their improper entry bythe end-users of usernames and/or passwords. The transaction accesscontrol system 100 addresses these and other issues as described hereinby assigning entry of the usernames and passwords into the requesterdatabase 114 to an administrator who most likely would be also assignedto enter the usernames and passwords in corresponding fashion into thedatabase of the external security manager 116.

[0047] The external communication module 114, running on the legacy hostdata system 80 outside of the internal transaction area 102, is designedto receive from the requester applications 121, standardized high-levellanguage based communication rather than computer terminal communicationexpected by the internal applications 104. The high-level languagesinclude, but are not limited to, High-Level Language ApplicationProgramming Interface (HLLAPI), Server Enterprise Class Library (SEACL),Host Publishing Interfaces such as QACOM (a set of HLLAPI styleinterfaces by Attachmate Corp., Bellevue, Washington), the OHIOspecification (created jointly between IBM Corp. and Attachmate Corp.,Bellevue, Washington), and various playback/record interfacesconventionally known as navigation, macros, and/or scripting.

[0048] The external communication module 110 is also designed to receivefrom the requester applications 121, direct binary communicationcompliant with the particular internal transaction area 102, such as IBMCICS or one related to IBM AS/400 or UNISYS operating systems, on thelegacy host data system 80 running the internal applications 104. Theexternal communication module 110 is configured to route receivedcommunication from the requester applications 121 to the proper accessstate controller 112 or other appropriate processes. The externalcommunication module 110 is also configured to convert externalcommunication received from the requester applications 121 that is notin binary form compliant with the internal transaction area 102, such asmarkup languages including XML and HTML and other forms using protocolssuch as including HTTP. If needed, the external communication module 110converts received communication into binary formatted data compliantwith the internal transaction area 102.

[0049] The exemplary implementation of FIG. 2 also has the listener 108,which listens for initial connect messages from the requesterapplications 121 and helps establish transaction links between therequester applications and the external communication module 110. Insome implementations, the operational combination of the access statecontroller 112 and the external communication module 110 results incommunication, through the host internal area access 113, betweenrequester applications 121 and the internal applications 104 running inthe internal transaction area 102. Communication is provided withoutend-users of the requester applications 121 requiring expertise directedtoward the host internal area access 113 and the internal transactionarea 102, such as with programming languages, architectures, datastructures, assembly languages, and other aspects. Examples of suchexpertise involves IBM CICS, IBM 3270 Bridge Exit, IBM CICS Front EndProgramming Interface (FEPI), or whatever mainframe integrationtechnology developers of the external applications used to drive theirlegacy mainframe internal applications. This expertise typicallyincludes knowledge of older programming and assembly languages and datastructures involved with such languages as COBOL, PL/1, 370 Assemblerand other languages. The expertise also generally includes, but is notlimited to, the internal architecture, pseudo-conversationaltransactions, and conversational transactions of the internaltransaction area, associated quasi-reentrant programming models,asynchronously started transactions, and continuity of multipleinstantiations of multiple internal applications to achieve some overallgoal. In other implementations, the requester applications 121 areconfigured using expertise directed toward the host internal area access113 such that less conversion and/or less state tracking is necessary bythe combination of the external communication module 110 and the accessstate controller 112. In some of these other implementations, theinternal transaction area 102 and the host internal area access 113 haveless demanding requirements for expertise thus allowing a configurationof the requester applications 121 more native to the internaltransaction area.

[0050] A communication diagram showing an exemplary interaction betweencomponents of a representative implementation of the transaction accesscontrol system 100, other components of the legacy host data system 80,and one of the end-user computers 120 is illustrated in FIG. 3. Asdepicted in this communication diagram, the end-user computer 120 firstsends a connect request 130 to the legacy host data system 80. Thelistener 108 receives the connect request 130 and passes socketidentification, network protocol address information of the end-usercomputer 120 (such as the IP or IPX address), and other user requestdata 132 to the external communication module 110. The externalcommunication module 110 then sends the network protocol addressinformation 134 (such as an IP or IPX address) of the end-user computer120 to the validator 118.

[0051] The validator 118 performs validation functions includingverifying that the network protocol address information corresponds to avalid network protocol address in accordance with the requester database114. Upon performing validation functions, the validator 118 then sendsto the external communication module 110 a connect response 136indicating whether the network protocol address 134 corresponds to avalid network protocol address. Based upon the connect response 136received from the validator 118, the external communication module 110will then send a connect response 138 to the end-user computer 120indicating the outcome of the connect request 130 as either a successfulor failed connection. If the connect request 130 is successful, theend-user computer 120 will then send a transaction request 140 to theexternal communication module 110. The external communication module 110will then send appropriate transaction request data 142 to the accessstate controller 112.

[0052] Upon receipt of the transaction request data 142, the accessstate controller 112 then sends information including the end-usercomputer network protocol address 134 and designating code of therequested transaction in the form of a message 144 to the validator 118.In response to the receipt of the message 144, the validator 118performs transaction validation functions based upon the end-usercomputer network protocol address 132 and the designating code of therequested transaction in accordance with the requester database 114.Implementations of the transaction access control system 100 can includethe following transaction validation functions: verification that therequested transaction is authorized for the network protocol address 132associated with requesting end-user computer 120, determination whetherthe requesting end-user computer should be issued a challenge to enterusername and password, determination whether the username and passwordsubmitted by the challenged end-user computer should be compared withthe username and password associated with the network protocol addressof the challenged end-user computer found in the requester database 114,and determination whether the code associated with the requestedtransaction is valid.

[0053] After performing transaction validation functions, the validator118 then sends a transaction response 146 to the access state controller112 containing instructions either challenging the end-user computer120, declining the transaction request 140, or accepting the transactionrequest. If the transaction response 146 contains instructions regardinga challenge or a decline, the access state controller 112 will then senda message 148 containing either a challenge or a decline to the externalcommunication module 110. The message 148 would contain a challenge ifthe validator 118 has determined that the end-user computer 120 shouldbe challenged to provide a username and password. On the other hand, themessage 148 would contain a decline if the validator 118 has determinedthat the end-user computer 120 should be notified that the requestedtransaction for the network protocol address 132 is invalid. Uponreceipt of the message 148, the external communication module 110 sendsa message 150 to the end-user computer 120 indicating either acorresponding challenge or decline. If the message 150 is a challenge,the end-user computer 120 will send a challenge response 152 to theexternal communication module 110 containing a submitted username andpassword. The external communication module 110 will then send achallenge response 154 with the submitted username and password to thevalidator 118. The submitted username and password will then be checkedby the validator 118 with respect to the requester database 114 and thevalidator will then send a challenge response 155 to the access statecontroller 112 indicating whether the submitted username and passwordwas valid or not.

[0054] As a consequence of receiving a valid challenge response 155 orof receiving instructions in the transaction response 146 to accept thetransaction request 140, the access state controller 112 will sendtransaction data 156 to a designated one of the internal applications104 via the host internal area access 113 if the validator hasdetermined that the transaction request is valid for the networkprotocol address 132 associated with the end-user computer 120 and thatno challenge is necessary. The transaction data 156 can include the username and password, in accordance with the requester database 114,associated with the network protocol address 132 if needed by theexternal security manager 116, which could be running as Resource AccessControl Facility (RACF), ACF, TopSecret, or other security packages. Ifthe username and password of the end-user of the end-user computer 120is needed in the transaction data 156, the external security manager 116first verifies the username and password before the transaction data issent to the internal transaction area 102 to be subsequently received bythe designated internal application 104. Although the implementation ofthe transaction access control system 100 includes the validator 118having validation functions described above, in other implementations ofthe transaction access control system, the validation functions areperformed by versions of the external communication module 110 and theaccess state controller 112 thereby eliminating the necessity for aseparate component or module for the validator.

[0055] Upon receipt of the transaction data 156, the internalapplication 104 performs the requested transaction and sends resultantresponse data 158 to the access state controller 112. Upon receipt ofthe response data 158, the access state controller 112 sends a responsedata 160 to the external communication module 110. Upon receipt of theresponse data 160, the external communication module 110 sends aresponse data 162 to the end-user computer 120.

[0056] An illustration of a method 170 of a representativeimplementation for the listener 108 to receive initial externalcommunication requests is shown in FIG. 4. The method 170 opens a socketfor the listener 108 to listen for initial connect requests sent fromone of the end-user computers 120 (step 172) and sets the socket in alisten state (step 174). When an initial connect request is heard by thelistener 108, the method 170 then pends an accept of a socket connectfrom the associated requester application 121 (step 176). Socketidentification for the requester application 121 is then received (step178). The external communication module 110 is then started tocommunicate with the requester application 121 (step 180) and the method170 then goes back to step 174.

[0057] An illustration of a method 190 of a representativeimplementation for the external communication module 110 is shown inFIGS. 5A, 5B, and 5C. According to the method 190, the externalcommunication module 110 receives a communication from one of therequester applications 121, a determination is made whether thecommunication is a connect request and if not (NO branch of decisionstep 192), a determination is made whether the communication is adisconnect request and if not (NO branch of decision step 194), adetermination is made whether the communication is a transaction requestand if not (NO branch of decision step 202), an error message is set(step 204) and the method 190 returns to the caller or ends.

[0058] If the communication is a connect request (YES branch of decisionstep 192), a method 210, illustrated in FIG. 5B, is executed starting bydetermining whether filtering is enabled and if so (YES branch ofdecision step 212), the network protocol address (such as an IP or IPXaddress) associated with the origination of the communication isvalidated (step 214) and the method goes to decision step 220. If thenetwork protocol address (such as an IP or IPX address) is valid (YESbranch of decision step 220), resources are allocated (step 226), asuccess message is sent (step 228) and the method 210 returns to thecaller or ends. If filtering is not enabled (NO branch of decision step212), resources are allocated (step 216), a success message is sent(step 218), and the method 210 returns to the caller or ends. If thenetwork protocol address (such as an IP or IPX address) is not valid (NObranch of decision step 220), a failure message is sent (step 222), thesocket connection associated with the communication is closed (step224), and the method 210 returns to the caller or ends. If thecommunication is a disconnect request (YES branch of decision step 194of FIG. 5A), internal resources are freed (step 196), a success messageis sent (step 198), and the method 190 returns to the caller or ends.

[0059] If the communication is a transaction request (YES branch ofdecision step 202), a method 230 is executed, illustrated in FIG. 5C,starting by determining whether validation has been enabled and if not(NO branch of decision step 232), the access state controller 112 iscalled (step 234), a response for the external application associatedwith the communication is formatted and sent (step 256), and the method230 returns to the caller or ends. Otherwise (YES branch of decisionstep 232), a determination is made whether a response has been receivedand if so (YES branch of decision step 236), a determination is madewhether an identification check is required and if so (YES branch ofdecision step 240), identification is verified in decision step 242. Ifan identification check is not required (NO branch of decision step240), the method 230 goes to step 234. If identification is not verified(NO branch of decision step 242), an error message is set (step 244),and the method 230 returns to the caller or ends. Otherwise (YES branchof decision step 242), the method 230 goes to step 234. If a responsehas not been received (NO branch of decision step 236), a determinationis made whether the communication is a start of a request and if not (NObranch of decision step 238), the method 230 goes to step 234. Otherwise(YES branch of decision step 238), the transaction is validated (step246). If the transaction is not valid (NO branch of decision step 248),an error message is set (step 250) and the method 230 returns to thecaller or ends. If the transaction is valid (YES branch of decision step248), determination is made whether identification is required and if so(YES branch of decision step 252), a message is set to supplyidentification (step 254) and the method 230 returns to the caller orends. Otherwise (NO branch of decision step 252), the method 230 goes tostep 234.

[0060] An illustration of a method 260 associated with the transactionaccess control system 100 regarding preparation by the validator 118 isprovided by FIG. 6. The method 260 has the requester database 114 readinto a host memory table of the legacy host data system 80 (step 262).The host memory table is then sorted by network protocol address (suchas an IP or IPX address) (step 264). The method 260 then returns to thecaller or ends.

[0061] An illustration of a method 270 associated with the transactionaccess control system 100 regarding user validation performed by thevalidator 118 on a network protocol address (such as an IP or PXaddress) contained in one of the connect requests 130 sent by one of theend-user computers 120 is provided by FIG. 7. The method 270 performedby the validator 118 parses the network protocol address 134 (such as anIP or IPX address) sent to the validator in a validation request by theexternal communication module 110 (step 272). If the network protocoladdress 134 is not in the host memory table containing the requesterdatabase 114 (NO branch of decision step 274), the validator 118indicates in the connect response 136 sent back to externalcommunication module 110 that the network protocol address (such as anIP or IPX address) is not authorized (step 276) and the method 270returns to the caller or ends. Otherwise (YES branch of decision step274), the validator 118 indicates in the connect response 136 sent backto external communication module 110 that the network protocol address134 (such as an IP or IPX address) is authorized (step 278) and themethod 270 returns to the caller or ends.

[0062] An illustration of a method 280 associated with the transactionaccess control system 100 regarding transaction validation performed bythe validator 118 on transaction request data contained in one of thetransaction requests 140 sent by one of the end-user computers 120 isprovided by FIG. 8. The method 280 performed by the validator 118 parsesthe network protocol address 134 (such as an IP or IPX address) of theend-user computer 120 contained by one of the messages 144 andtransaction request code sent to the validator within one of themessages 144 containing the network protocol address 134 (such as an IPor IPX address) of the end-user computer 120 by the access statecontroller 112 (step 282). The validator 118 then determines, based uponthe network protocol address 134 and the code of the transaction requestfound in the message 144, the appropriate response to send back to theaccess state controller 112. Based upon this determination, thevalidator 118 then sends one of the transaction responses 146 back tothe access state controller 112 indicating whether the transactionrequest has been authorized, has been denied, or whether the end-usercomputer 120 must be challenged for a username and password (step 284)and the method 280 returns to the caller or ends.

[0063] An illustration of a method 290 containing a more detailedrepresentative example associated with the transaction access controlsystem 100 regarding transaction validation performed by the validator118 on a transaction request contained in one of the connect requests140 sent by one of the end-user computers 120 is provided by FIG. 9. Themethod 290 performed by the validator 118 parses the network protocoladdress 134 (such as an IP or IPX address) of the end-user computer 120contained by one of the messages 144 and transaction request code sentto the validator within one of the messages 144 containing the networkprotocol address 134 (such as an IP or IPX address) of the end-usercomputer 120 by the access state controller 112 (step 292). Thevalidator 118 then determines, based upon the network protocol address134 and the code of the transaction request found in the message 144,the appropriate response to send back to the access state controller112. Based upon this determination, the validator 118 then sends one ofthe transaction responses 146 back to the access state controller 112indicating whether the transaction request has been authorized, has beendenied, or whether the end-user computer 120 must be challenged for ausername and password. For instance, if the validator 118 determinesthat the requested transaction is unknown to the internal transaction102 (NO branch of decision step 294), the validator returns thetransaction response 146 to the access state controller 112 indicatingthat the transaction is invalid (step 296) and the method 290 returns tothe caller or ends. Otherwise (YES branch of decision step 294), if thevalidator 118 determines that the network protocol address 134 is notauthorized (NO branch of decision step 298), the validator returns thetransaction response 146 to the access state controller 112 indicatingthat the network protocol address is not authorized (step 300) and themethod 290 returns to the caller or ends. Otherwise (YES branch ofdecision step 298), if the validator 118 determines that the end-usercomputer 120 should not be challenged for a usename and password (NObranch of decision step 302), the validator returns the transactionresponse 146 to the access state controller 112 indicating that thetransaction request is authorized and no challenges for username andpassword are necessary (step 304) and the method 290 returns to thecaller or ends. Otherwise (YES branch of decision step 302), if thevalidator 118 determines that the username and password submitted by theend-user computer 120 in response to the challenge does not need to becompared with the requester database 114 before sending them to theexternal security manager 116 (NO branch of decision step 306), thevalidator returns the transaction response 146 to the access statecontroller 112 indicating that the transaction request is authorized,the end-user computer should be challenged for username and password,and that the username and password submitted by the end-user computerdoes not need to be compared (step 308) and the method 290 returns tothe caller or ends. Otherwise (YES branch of decision step 306), thevalidator returns the transaction response 146 to the access statecontroller 112 indicating that the transaction request is authorized,the end-user computer 120 should be challenged for username andpassword, and that the username and password submitted by the end-usercomputer is to be compared with the requester database 114 beforesending them to the external security manager 116 (step 310) and themethod 290 returns to the caller or ends.

[0064] From the foregoing it will be appreciated that, although specificimplementations of the invention have been described herein for purposesof illustration, various modifications may be made without deviatingfrom the spirit and scope of the invention. Accordingly, the inventionis not limited except as by the appended claims.

The invention claimed is:
 1. For use with an internal transaction areaand an internal application running in the internal transaction area ona host computer connected to a network, for use with an externalsecurity manager configured to receive and authenticate a firstplurality of pairs of usernames and passwords to permit or deny accessto the internal transaction area, and for use with a first plurality ofend-user computers communicatively linked to the host computer via thenetwork, the end-user computers each having at least one of a firstplurality of network protocol addresses and a requester application, atransaction access control system comprising: a requester databaseconfigured to contain for each of the first plurality of networkprotocol addresses of the first plurality of end-user computers, anassociated one of the first plurality of pairs of usernames andpasswords; a controller configured to receive the first plurality ofnetwork protocol addresses sent from the first plurality of the end-usercomputers via the network and received by the host computer; and avalidator configured to retrieve from the requester database each of thefirst plurality of username and password pairs associated with each ofthe first plurality of network protocol addresses based upon at leasteach of the first plurality of network protocol addresses, thecontroller being configured to transmit each of the retrieved usernameand password pairs to be authenticated by the external security managerto permit access to the internal transaction area to each of therequester applications of the end-user computers having the firstplurality of network protocol addresses which are associated with theretrieved username and password pairs.
 2. The system of claim 1 whereinthe controller is configured to run on the host computer.
 3. The systemof claim 1, further including a configurator configured to configureinformation in the requester database.
 4. The system of claim 3 whereinthe configurator is configured to run on the host computer.
 5. Thesystem of claim 3 wherein the configurator is communicatively linked tothe host computer via the network.
 6. The system of claim 1, furtherincluding a listener configured to receive connect requests sent byend-user computers including the first plurality of end-user computersand other end-user computers, the connect requests containing the atleast one of the network protocol address of the sending end-usercomputer, and configured to forward the at least one of the networkprotocol address of the sending end-user computers to be received by thevalidator, and wherein the validator is further configured to determinewhether the network protocol addresses of the sending end-user computersare contained in the requester database.
 7. The system of claim 1wherein the requester application of the end-user computer is configuredto send transaction codes to the host computer to initiate transactionsassociated with the internal application, wherein the requester databaseis further configured to contain information associated with thetransaction codes for each network protocol address, wherein thecontroller is further configured to receive the transaction codes sentby the end-user computer and received by the host computer to forward tothe validator, and wherein the validator is further configured toretrieve each of the username and password pairs associated with each ofthe first plurality of network protocol addresses based further upon theinformation associated with the transaction codes contained in therequester database.
 8. The system of claim 7 wherein each of thetransactions have execution priorities further associated with thetransaction codes that initiate each transaction.
 9. The system of claim7 wherein the transactions have execution priorities associated with theat least one network protocol address of the end-user computer of therequester application that sent the transaction codes to the hostcomputer.
 10. The system of claim 9 wherein each of the transactionshave execution priorities further associated with the transaction codesthat initiate each transaction.
 11. The system of claim 7 wherein theinformation associated with the transaction codes indicates that some ofthe transactions associated with the transaction codes are not to bepermitted access to the internal transaction access area for a selectnumber of the first plurality of network protocol addresses associatedwith a select number of the first plurality of end-user computers. 12.The system of claim 11 wherein the select number of the first pluralityof network protocol addresses includes all of the first plurality ofnetwork protocol addresses.
 13. The system of claim 1 wherein therequester database is further configured to contain for each of a secondplurality of network protocol addresses of a second plurality ofend-user computers, an associated one of a second plurality of pairs ofusernames and passwords and further configured to contain challengeinformation indicating at least that the second plurality of end-usercomputers must be challenged to send one of the second plurality ofpairs of usernames and passwords to the host computer, and wherein theexternal security manager is further configured to receive andauthenticate the second plurality of pairs of usernames and passwords.14. The system of claim 13 wherein the validator is further configuredto determine that one of the second plurality of an end-user computershaving one of the second plurality of network protocol addressesreceived by the host computer is to be challenged to send a username andpassword.
 15. The system of claim 14 wherein the validator is furtherconfigured to determine whether a username and password pair sent fromone of the second plurality of end-user computers having one of thesecond plurality of network protocol addresses should be compared withthe usename and password pair in the requester database associated withthe same one of the second plurality of network protocol addresses. 16.The system of claim 1, further including an external communicationmodule configured to receive a first communication and a secondcommunication from the requester applications, the first communicationbeing formatted in a first format and based on a non-compliant language,the non-compliant language being non-compliant with the internaltransaction area, the second communication being formatted in a secondformat compliant with the internal transaction area and based on acompliant language, the compliant language being compliant with theinternal transaction area, the external communication module configuredto convert the format of the first communication from the first formatinto the second format, the external communication module configured toreceive an internal communication originating from the internalapplications having the second format, the external communication moduleconfigured to convert, if needed, the format of the received internalcommunication from the second format into the first format, andconfigured to send the internal communication to the requesterapplications, at least in part, upon addressing of the internalcommunication.
 17. The system of claim 16 wherein the externalcommunication module is configured to run on the host computer.
 18. Thesystem of claim 16 wherein the internal transaction area is based on IBMCICS and the external communication module is configured to convertcommunication having non-compliant language into communication havinglanguage compliant with IBM CICS.
 19. The system of claim 16 wherein thenon-compliant language is one of the following: HLLAPI and SEACL. 20.For use with an internal transaction area and an internal applicationrunning in the internal transaction area on a host computer connected toa network, for use with an external security manager configured toreceive and authenticate a first plurality of pairs of usernames andpasswords to permit or deny access to the internal transaction area, andfor use with a first plurality of end-user computers communicativelylinked to the host computer via the network, the end-user computers eachhaving at least one of a first plurality of network protocol addressesand a requester application, a method comprising: containing for each ofthe first plurality of network protocol addresses of the first pluralityof end-user computers, an associated one of the first plurality of pairsof usernames and passwords; receiving the first plurality of networkprotocol addresses sent from the first plurality of the end-usercomputers via the network and received by the host computer; retrievingfrom the requester database each of the first plurality of username andpassword pairs associated with each of the first plurality of networkprotocol addresses based upon at least each of the first plurality ofnetwork protocol addresses; and transmitting each of the retrievedusername and password pairs to be authenticated by the external securitymanager to permit access to the internal transaction area to each of therequester applications of the end-user computers having the firstplurality of network protocol addresses which are associated with theretrieved username and password pairs.
 21. The method of claim 20,further including configuring information in the requester database. 22.The method of claim 21 wherein the configuring is performed via acommunication link to the host computer via the network.
 23. The methodof claim 20, further including receiving connect requests sent byend-user computers including the first plurality of end-user computersand other end-user computers, the connect requests containing the atleast one network protocol address of the sending end-user computer, andforwarding the at least one network protocol address of the sendingend-user computers to be received by the validator; and furtherincluding determining whether the network protocol addresses of thesending end-user computers are contained in the requester database. 24.The method of claim 20 wherein the requester application of the end-usercomputer is configured to send transaction codes to the host computer toinitiate transactions associated with the internal application, andfurther including containing information associated with the transactioncodes for each network protocol address, receiving the transaction codessent by the end-user computer and received by the host computer toforward to the validator, and retrieving each of the usename andpassword pairs associated with each of the first plurality of networkprotocol addresses based further upon the information associated withthe transaction codes contained in the requester database.
 25. Themethod of claim 24 wherein the transactions have execution prioritiesassociated with their transaction codes.
 26. The method of claim 24wherein the transactions have execution priorities associated with theat least one network protocol address of the end-user computer of therequester application that sent the transaction codes to the hostcomputer.
 27. The method of claim 26 wherein each of the transactionshave execution priorities further associated with the transaction codesthat initiate each transaction.
 28. The method of claim 24 wherein theinformation associated with the transaction codes indicates that some ofthe transactions associated with the transaction codes are not to bepermitted access to the internal transaction access area for a selectnumber of the first plurality of network protocol addresses associatedwith a select number of the first plurality of end-user computers. 29.The method of claim 28 wherein the select number of the first pluralityof network protocol addresses includes all of the first plurality ofnetwork protocol addresses.
 30. The method of claim 20, furtherincluding containing for each of a second plurality of network protocoladdresses of a second plurality of end-user computers, an associated oneof a second plurality of pairs of usernames and passwords, containingchallenge information indicating at least that the second plurality ofend-user computers must be challenged to send one of the secondplurality of pairs of usernames and passwords to the host computer, andwherein the external security manager is further configure to receiveand authenticate the second plurality of pairs of usernames andpasswords.
 31. The method of claim 30, further comprising determiningthat one of the second plurality of an end-user computers having one ofthe second plurality of network protocol addresses received by the hostcomputer is to be challenged to send a username and password.
 32. Themethod of claim 31, further comprising determining whether a usernameand password pair sent from one of the second plurality of end-usercomputers having one of the second plurality of network protocoladdresses should be compared with the username and password pair in therequester database associated with the same one of the second pluralityof network protocol addresses.
 33. The method of claim 20, furtherincluding receiving a first communication and a second communicationfrom the requester applications, the first communication being formattedin a first format and based on a non-compliant language, thenon-compliant language being non-compliant with the internal transactionarea, the second communication being formatted in a second formatcompliant with the internal transaction area and based on a compliantlanguage, the compliant language being compliant with the internaltransaction area, converting the format of the first communication fromthe first format into the second format, receiving an internalcommunication originating from the internal applications having thesecond format, converting, if needed, the format of the receivedinternal communication from the second format into the first format, andsending the internal communication to the requester applications, atleast in part, upon addressing of the internal communication.
 34. Themethod of claim 33 wherein the internal transaction area is based on IBMCICS and further comprising converting communication havingnon-compliant language into communication having language compliant withIBM CICS.
 35. The method of claim 33 wherein the non-compliant languageis one of the following: HLLAPI and SEACL.
 36. For use with an internaltransaction area and an internal application running in the internaltransaction area on a host computer connected to a network, for use withan external security manager configured to receive and authenticate afirst plurality of pairs of usernames and passwords to permit or denyaccess to the internal transaction area, and for use with a firstplurality of end-user computers communicatively linked to the hostcomputer via the network, the end-user computers each having at leastone of a first plurality of network protocol addresses and a requesterapplication, a computer-readable medium whose contents cause a computerto perform by: containing for each of the first plurality of networkprotocol addresses of the first plurality of end-user computers, anassociated one of the first plurality of pairs of usernames andpasswords; receiving the first plurality of network protocol addressessent from the first plurality of the end-user computers via the networkand received by the host computer; retrieving from the requesterdatabase each of the first plurality of username and password pairsassociated with each of the first plurality of network protocoladdresses based upon at least each of the first plurality of networkprotocol addresses; and transmitting each of the retrieved username andpassword pairs to be authenticated by the external security manager topermit access to the internal transaction area to each of the requesterapplications of the end-user computers having the first plurality ofnetwork protocol addresses which are associated with the retrievedusername and password pairs.
 37. The computer-readable medium of claim36, whose contents further cause a computer to perform by: configuringinformation in the requester database.
 38. The computer-readable mediumof claim 37 wherein the configuring is performed via a communicationlink to the host computer via the network.
 39. The computer-readablemedium of claim 36, whose contents further cause a computer to performby: receiving connect requests sent by end-user computers including thefirst plurality of end-user computers and other end-user computers, theconnect requests containing the at least one network protocol address ofthe sending end-user computer, and forwarding the at least one networkprotocol address of the sending end-user computers to be received by thevalidator; and whose contents further cause a computer to perform bydetermining whether the network protocol addresses of the sendingend-user computers are contained in the requester database.
 40. Thecomputer-readable medium of claim 36 wherein the requester applicationof the end-user computer is configured to send transaction codes to thehost computer to initiate transactions associated with the internalapplication, and whose contents further cause a computer to perform bycontaining information associated with the transaction codes for eachnetwork protocol address, receiving the transaction codes sent by theend-user computer and received by the host computer to forward to thevalidator, and retrieving each of the username and password pairsassociated with each of the first plurality of network protocoladdresses based further upon the information associated with thetransaction codes contained in the requester database.
 41. Thecomputer-readable medium of claim 40 wherein the transactions haveexecution priorities associated with their transaction codes.
 42. Thecomputer-readable medium of claim 40 wherein the transactions haveexecution priorities associated with the at least one network protocoladdress of the end-user computer of the requester application that sentthe transaction codes to the host computer.
 43. The computer-readablemedium of claim 42 wherein each of the transactions have executionpriorities further associated with the transaction codes that initiateeach transaction.
 44. The computer-readable medium of claim 40 whereinthe information associated with the transaction codes indicates thatsome of the transactions associated with the transaction codes are notto be permitted access to the internal transaction access area for aselect number of the first plurality of network protocol addressesassociated with a select number of the first plurality of end-usercomputers.
 45. The computer-readable medium of claim 44 wherein theselect number of the first plurality of network protocol addressesincludes all of the first plurality of network protocol addresses. 46.The computer-readable medium of claim 36, whose contents further cause acomputer to perform by containing for each of a second plurality ofnetwork protocol addresses of a second plurality of end-user computers,an associated one of a second plurality of pairs of usernames andpasswords, containing challenge information indicating at least that thesecond plurality of end-user computers must be challenged to send one ofthe second plurality of pairs of usernames and passwords to the hostcomputer, and wherein the external security manager is further configureto receive and authenticate the second plurality of pairs of usernamesand passwords.
 47. The computer-readable medium of claim 36, whosecontents further cause a computer to perform by determining that one ofthe second plurality of an end-user computers having one of the secondplurality of network protocol addresses received by the host computer isto be challenged to send a username and password.
 48. Thecomputer-readable medium of claim 47, whose contents further cause acomputer to perform by determining whether a username and password pairsent from one of the second plurality of end-user computers having oneof the second plurality of network protocol addresses should be comparedwith the username and password pair in the requester database associatedwith the same one of the second plurality of network protocol addresses.49. The computer-readable medium of claim 36, whose contents furthercause a computer to perform by receiving a first communication and asecond communication from the requester applications, the firstcommunication being formatted in a first format and based on anon-compliant language, the non-compliant language being non-compliantwith the internal transaction area, the second communication beingformatted in a second format compliant with the internal transactionarea and based on a compliant language, the compliant language beingcompliant with the internal transaction area, converting the format ofthe first communication from the first format into the second format,receiving an internal communication originating from the internalapplications having the second format, converting, if needed, the formatof the received internal communication from the second format into thefirst format, and sending the internal communication to the requesterapplications, at least in part, upon addressing of the internalcommunication.
 50. The computer-readable medium of claim 49 wherein theinternal transaction area is based on IBM CICS and further comprisingconverting communication having non-compliant language intocommunication having language compliant with IBM CICS.
 51. Thecomputer-readable medium of claim 49 wherein the non-compliant languageis one of the following: HLLAPI and SEACL.
 52. For use with an internaltransaction area and an internal application running in the internaltransaction area on a host computer connected to a network, for use withan external security manager configured to receive and authenticate afirst plurality of pairs of usernames and passwords to permit or denyaccess to the internal transaction area, and for use with a firstplurality of end-user computers communicatively linked to the hostcomputer via the network, the end-user computers each having at leastone of a first plurality of network protocol addresses and a requesterapplication, a transaction control system comprising: means forcontaining for each of the first plurality of network protocol addressesof the first plurality of end-user computers, an associated one of thefirst plurality of pairs of usernames and passwords; means for receivingthe first plurality of network protocol addresses sent from the firstplurality of the end-user computers via the network and received by thehost computer; means for retrieving from the requester database each ofthe first plurality of username and password pairs associated with eachof the first plurality of network protocol addresses based upon at leasteach of the first plurality of network protocol addresses; and means fortransmitting each of the retrieved username and password pairs to beauthenticated by the external security manager to permit access to theinternal transaction area to each of the requester applications of theend-user computers having the first plurality of network protocoladdresses which are associated with the retrieved username and passwordpairs.
 53. The system of claim 52, further including means forconfiguring information in the requester database.
 54. The system ofclaim 53 wherein the means for configuring is performed via acommunication link to the host computer via the network.
 55. The systemof claim 52, further including means for receiving connect requests sentby end-user computers including the first plurality of end-usercomputers and other end-user computers, the connect requests containingthe at least one network protocol address of the sending end-usercomputer, and means for forwarding the at least one network protocoladdress of the sending end-user computers to be received by thevalidator; and further including means for determining whether thenetwork protocol addresses of the sending end-user computers arecontained in the requester database.
 56. The system of claim 52 whereinthe requester application of the end-user computer is configured to sendtransaction codes to the host computer to initiate transactionsassociated with the internal application, and further including meansfor containing information associated with the transaction codes foreach network protocol address, means for receiving the transaction codessent by the end-user computer and received by the host computer toforward to the validator, and means for retrieving each of the usenameand password pairs associated with each of the first plurality ofnetwork protocol addresses based further upon the information associatedwith the transaction codes contained in the requester database.
 57. Thesystem of claim 56 wherein the transactions have execution prioritiesassociated with their transaction codes.
 58. The system of claim 56wherein the transactions have execution priorities associated with theat least one network protocol address of the end-user computer of therequester application that sent the transaction codes to the hostcomputer.
 59. The system of claim 58 wherein each of the transactionshave execution priorities further associated with the transaction codesthat initiate each transaction.
 60. The system of claim 56 wherein theinformation associated with the transaction codes indicates that some ofthe transactions associated with the transaction codes are not to bepermitted access to the internal transaction access area for a selectnumber of the first plurality of network protocol addresses associatedwith a select number of the first plurality of end-user computers. 61.The system of claim 60 wherein the select number of the first pluralityof network protocol addresses includes all of the first plurality ofnetwork protocol addresses.
 62. The system method of claim 52, furtherincluding means for containing for each of a second plurality of networkprotocol addresses of a second plurality of end-user computers, anassociated one of a second plurality of pairs of usernames andpasswords, means for containing challenge information indicating atleast that the second plurality of end-user computers must be challengedto send one of the second plurality of pairs of usernames and passwordsto the host computer, and wherein the external security manager isfurther configure to receive and authenticate the second plurality ofpairs of usernames and passwords.
 63. The system of claim 62, furthercomprising means for determining that one of the second plurality of anend-user computers having one of the second plurality of networkprotocol addresses received by the host computer is to be challenged tosend a username and password.
 64. The system of claim 63, furthercomprising means for determining whether a username and password pairsent from one of the second plurality of end-user computers having oneof the second plurality of network protocol addresses should be comparedwith the username and password pair in the requester database associatedwith the same one of the second plurality of network protocol addresses.65. The system of claim 52, further including means for receiving afirst communication and a second communication from the requesterapplications, the first communication being formatted in a first formatand based on a non-compliant language, the non-compliant language beingnon-compliant with the internal transaction area, the secondcommunication being formatted in a second format compliant with theinternal transaction area and based on a compliant language, thecompliant language being compliant with the internal transaction area,means for converting the format of the first communication from thefirst format into the second format, means for receiving an internalcommunication originating from the internal applications having thesecond format, means for converting, if needed, the format of thereceived internal communication from the second format into the firstformat, and means for sending the internal communication to therequester applications, at least in part, upon addressing of theinternal communication.
 66. The system of claim 65 wherein the internaltransaction area is based on IBM CICS and further comprising means forconverting communication having non-compliant language intocommunication having language compliant with IBM CICS.
 67. The system ofclaim 65 wherein the non-compliant language is one of the following:HLLAPI and SEACL.